home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 16259 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.0 KB

  1. Path: news.nyu.edu!schonberg!dewar
  2. From: dewar@cs.nyu.edu (Robert Dewar)
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
  4. Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)
  5. Date: 9 Apr 1996 21:57:00 -0400
  6. Organization: Courant Institute of Mathematical Sciences
  7. Message-ID: <dewar.829101156@schonberg>
  8. References: <JSA.96Feb16135027@organon.com> <dewar.828936837@schonberg> <828964950snz@genesis.demon.co.uk> <dewar.828987544@schonberg> <4kbuebINNrho@keats.ugrad.cs.ubc.ca> <dewar.829048603@schonberg> <4kets3$ic0@news-s01.ny.us.ibm.net>
  9. NNTP-Posting-Host: schonberg.cs.nyu.edu
  10. X-Newsreader: NN version 6.5.0 (NOV)
  11.  
  12. Mike said
  13.  
  14. "SIGSEGV is invited, not by any "statement of semantics", but by careless
  15. code. If you use these functions without reasonable care, then you
  16. experience the consequences. If you do this for a living, you learn not
  17. to waste time on unnecessary chances."
  18.  
  19. No, that's confused. First of all, the clear specifications of most
  20. specific systems, e.g. SunOS, GUARANTEE *not* to give a sigsegv for
  21. the call in question. Linux may or may nt give a SIGSEGV depending
  22. on the luck of the draw (where the buffer is in memory). 
  23.  
  24. Basically the original code (not mine incidentally, I never write in
  25. C these days), was taking a short cut that was reasonably safe on
  26. most systems, and this "bug" might have survived for ever in the
  27. absence of the check in Linux + the happenstance that the buffr
  28. was near the end of memory. 
  29.  
  30. True, if someone appended to the file while it was being compiled,
  31. disaster could have struck, but most compilers and assemblers
  32. tend to assume that this is unlikely and of course in systems
  33. with decent file protection it is impossible. So for example,
  34. the code as originally written is 100% reliable on OS/2.
  35.  
  36. Of course writing portable code requires careful consideration
  37. of various possibilities, and failure to be careful certainly
  38. results in portability problems. But it is clear that if the
  39. spec for read had been clearer, this bug would NOT have been
  40. present in the first place!
  41.  
  42.